<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!--
Generated from $Fink: porting.en.xml,v 1.8 2007/02/23 22:04:55 rangerrick Exp $
-->
<title>Fink Documentation - Porting Unix software to Darwin and Mac OS X</title></head><body>
<table width="100%" cellspacing="0">
<tr valign="bottom">
<td align="center">
Available Languages:  | 
English | 
<a href="porting.fr.html">Fran&ccedil;ais</a> | 
<a href="porting.ja.html">&#26085;&#26412;&#35486; (Nihongo)</a> | 
<a href="porting.zh.html">&#20013;&#25991; (&#31616;) (Simplified Chinese)</a> | 
</td>
</tr>
</table>
<h1 style="text-align: center;">Porting Unix software to Darwin and Mac OS X</h1>
		<p>This document contains hints for porting Unix applications to Darwin and Mac OS X. Much of the information here applies to both Mac OS X version 10.x.x and "pure" Darwin systems. Both systems will be referred to as Darwin, since Mac OS X is actually a superset of Darwin.</p>
	<h2>Contents</h2><ul><li><a href="#basics"><b>1 Basics</b></a><ul><li><a href="#basics.heritage">1.1 Where Darwin came from</a></li><li><a href="#basics.compiler">1.2 The Compiler and Tools</a></li><li><a href="#basics.host-type">1.3 Host type</a></li><li><a href="#basics.libraries">1.4 Libraries</a></li><li><a href="#basics.other-sources">1.5 Other sources of information</a></li></ul></li><li><a href="#shared"><b>2 Shared Code</b></a><ul><li><a href="#shared.lib-and-mod">2.1 Shared Libraries vs. Loadable Modules</a></li><li><a href="#shared.version">2.2 Version Numbering</a></li><li><a href="#shared.cflags">2.3 Compiler Flags</a></li><li><a href="#shared.build-lib">2.4 Building a Shared Library</a></li><li><a href="#shared.build-mod">2.5 Building a Module</a></li></ul></li><li><a href="#libtool"><b>3 GNU libtool</b></a><ul><li><a href="#libtool.situation">3.1 The Situation</a></li><li><a href="#libtool.patch-135">3.2 The 1.3.5 Patch</a></li><li><a href="#libtool.fixing-14x">3.3 Fixing 1.4.x</a></li><li><a href="#libtool.notes">3.4 Further Notes</a></li></ul></li><li><a href="#preparing-10.2"><b>4 Preparing for 10.2</b></a><ul><li><a href="#preparing-10.2.bash">4.1 The bash shell</a></li><li><a href="#preparing-10.2.gcc3">4.2 The gcc3 compiler</a></li></ul></li><li><a href="#preparing-10.3"><b>5 Preparing for 10.3</b></a><ul><li><a href="#preparing-10.3.perl">5.1 Perl</a></li><li><a href="#preparing-10.3.typedef">5.2 New symbol definitions</a></li><li><a href="#preparing-10.3.system-libs">5.3 New builtin system libraries</a></li></ul></li><li><a href="#preparing-10.4"><b>6 Preparing for 10.4</b></a><ul><li><a href="#preparing-10.4.perl">6.1 Perl</a></li><li><a href="#preparing-10.4.typedef">6.2 New symbol definitions</a></li><li><a href="#preparing-10.4.system-libs">6.3 New builtin system libraries</a></li></ul></li></ul><h2><a name="basics">1 Basics</a></h2>
		
		

		<h3><a name="basics.heritage">1.1 Where Darwin came from</a></h3>

			<p>Darwin is a Unix-like operating system that evolved from NeXTStep / OpenStep. Lore has it that it was initially forked off 4.4BSD Lite. The BSD heritage still shows, in fact Darwin was recently modernized with code from FreeBSD and NetBSD.</p>

			<p>Darwin's kernel is based on a combination of Mach 3.0, BSD, and proprietary functionality like the object-oriented driver layer IOKit. Although Mach originally is a micro-kernel design, the BSD kernel that sits on top of it is monolithic and the two are now so intertwined that they must be regarded as a single monolithic kernel.</p>

			<p>The user-space tools and libraries shipped with Darwin are mostly of the BSD persuation, as opposed to the GNU tools you get with Linux. Apple is not as strict as other BSDs though, and goes for useful compromises. For example, Apple ships both BSD make and GNU make, with GNU make installed as the default.</p>
		
		

		<h3><a name="basics.compiler">1.2 The Compiler and Tools</a></h3>
			
			
			<p>Short story: The compiler is a gcc derivate, but installed as <tt style="white-space: nowrap;">cc</tt>; you may have to patch Makefiles. Most packages won't build shared libraries. If you get errors related to macros, use the <tt style="white-space: nowrap;">-no-cpp-precomp</tt> option.</p>

			<p>Long story: The compiler tool chain in the Mac OS X Developer Tools is a strange beast. The compiler is based on the gcc 2.95.2 suite, with modifications to support the Objective C language and some Darwin quirks. The preprocessor (<tt style="white-space: nowrap;">cpp</tt>) is available in two versions. One is the standard precompiler (from gcc 2.95.2), the other one is a special precompiler written by Apple, with support for precompiled headers. The latter one is used by default, because it is faster. However, some code doesn't compile with Apple's precompiler, so you must use the <tt style="white-space: nowrap;">-no-cpp-precomp</tt> option to get the standard precompiler. (Note: I previously recommended the <tt style="white-space: nowrap;">-traditional-cpp</tt> option. The semantics of this option have changed slightly with GCC 3, breaking most packages that use it. <tt style="white-space: nowrap;">-no-cpp-precomp</tt> has the desired effect on both the current Developer Tools and future compilers based on GCC 3.)</p>

			<p>The assembler says it's based on gas 1.38. The linker is not based on GNU tools. This is a problem when building shared libraries, as GNU libtool and configure scripts generated by it don't know how to handle Apple's linker.</p>
		
		

		<h3><a name="basics.host-type">1.3 Host type</a></h3>
			
			
			<p>Short story: If configure fails with 'Can't determine host type', copy config.guess and config.sub from /usr/share/libtool (/usr/libexec for OS versions prior to 10.2) into the current directory.</p>

			<p>Long story: The GNU world uses a canonical format to specify system types. It has three parts: cpu type, manufacturer and operating system. Sometimes a fourth part is added - then the third part denotes the kernel, while the fourth denotes the operating system. All parts are lower case and concatenated using dashes. Some examples: <tt style="white-space: nowrap;">i586-pc-linux-gnu</tt>, <tt style="white-space: nowrap;">hppa1.1-hp-hpux10.20</tt>, <tt style="white-space: nowrap;">sparc-sun-solaris2.6</tt>. The host type for Mac OS X 10.0 is <tt style="white-space: nowrap;">powerpc-apple-darwin1.3</tt>. Versions of Mac OS X 10.2 bring various <tt style="white-space: nowrap;">powerpc-apple-darwin6.x.0</tt> and 10.3 gives <tt style="white-space: nowrap;">powerpc-apple-darwin7.x.0</tt>, where "x" depends on the exact OS version.</p>

			<p>Many packages that use autoconf want to know the host type of the system they are compiled on. (Side note: to support cross-compiling and porting, there are actually three types - the host type, the build type and the target type. Usually, they're all the same.) You can either pass the host type to the configure script as a parameter or you can let it guess.</p>

			<p>The configure script uses two companion scripts to determine host types. <tt style="white-space: nowrap;">config.guess</tt> tries to guess the host type, <tt style="white-space: nowrap;">config.sub</tt> is used to validate and canonicalize the host type. These scripts are maintained as separate entities, but they are included in every package that uses them. Until very recently, these scripts didn't know about Darwin or Mac OS X. If you have a package that doesn't recognize Darwin, you must replace the config.guess and config.sub included in the package. Luckily, Apple put working versions in /usr/share/libtool (/usr/libexec for pre-10.2 OS), so you can just copy them from there.</p>

			<p>If you are constructing a Fink package, you can use the <tt style="white-space: nowrap;">UpdateConfigGuess</tt> and/or <tt style="white-space: nowrap;">UpdateConfigGuessInDirs</tt> fields in your <tt style="white-space: nowrap;">.info</tt> package description file to do this update automatically.</p>

		

		<h3><a name="basics.libraries">1.4 Libraries</a></h3>
			

			<p>Short story: You can safely remove <tt style="white-space: nowrap;">-lm</tt> from Makefiles, but you don't need to.</p>

			<p>Long story: Mac OS X doesn't have separate libc, libm, libcurses, libpthread etc. libraries. Instead, they're all part of the system library, libSystem. (In earlier versions, this actually was the System framework.) However, Apple placed appropriate symlinks in /usr/lib, so linking with <tt style="white-space: nowrap;">-lm</tt> will work. The only exception is <tt style="white-space: nowrap;">-lutil</tt>. On other systems, libutil contains functions related to pseudo-terminals and login accounting. These functions are in libSystem, but there is no symlink to provide a libutil.dylib.</p>

		

		<h3><a name="basics.other-sources">1.5 Other sources of information</a></h3>
			

			<p>Another source of information for porting is the Wiki at <a href="http://www.metapkg.org/wiki">MetaPkg Wiki</a>.</p>

			<p>You can also read Apple Technical Note <a href="http://developer.apple.com/technotes/tn2002/tn2071.html">TN2071</a>: "Porting Command Line Unix Tools to Mac OS X".</p>

		

	<h2><a name="shared">2 Shared Code</a></h2>
		
		

		<h3><a name="shared.lib-and-mod">2.1 Shared Libraries vs. Loadable Modules</a></h3>
			
			

			<p>One Mach-O feature that hits many people by surprise is the strict distinction between shared libraries and dynamically loadable modules. On ELF systems both are the same; any piece of shared code can be used as a library and for dynamic loading. Use <tt style="white-space: nowrap;">otool -hv <b>some_file</b></tt> to see the filetype of <tt style="white-space: nowrap;">some_file</tt>.</p>

			<p>Mach-O shared libraries have the file type MH_DYLIB and carry the extension <tt style="white-space: nowrap;">.dylib</tt>. They can be linked against with the usual static linker flags, e.g. <tt style="white-space: nowrap;">-lfoo</tt> for libfoo.dylib. However, they can not be loaded as a module. (Side note: Shared libraries can be loaded dynamically through an API. However, that API is different from the API for bundles and the semantics make it useless for an <tt style="white-space: nowrap;">dlopen()</tt> emulation. Most notably, shared libraries can not be unloaded.)</p>

			<p>Loadable modules are called "bundles" in Mach-O speak. They have the file type MH_BUNDLE. Since no component involved cares about it, they can carry any extension. The extension <tt style="white-space: nowrap;">.bundle</tt> is recommended by Apple, but most ported software uses <tt style="white-space: nowrap;">.so</tt> for the sake of compatibility. Bundles can be dynamically loaded and unloaded via dyld APIs, and there is a wrapper that emulates <tt style="white-space: nowrap;">dlopen()</tt> on top of that API. It is not possible to link against bundles as if they were shared libraries. However, it is possible that a bundle is linked against real shared libraries; those will be loaded automatically when the bundle is loaded.</p>

		

		<h3><a name="shared.version">2.2 Version Numbering</a></h3>
			

			<p>On an ELF system, version numbers are usually appended to the file name of the shared library after the extension, e.g. <tt style="white-space: nowrap;">libqt.so.2.3.0</tt>. On Darwin, the version numbers are placed between the library name and the extension, e.g. <tt style="white-space: nowrap;">libqt.2.3.0.dylib</tt>. Note that this allows you to request a specific version of the library when linking, using <tt style="white-space: nowrap;">-lqt.2.3.0</tt> for the example above.</p>

			<p>When creating a shared library, you can specify a name to be used when searching for the library at run time. This is usual practice and allows several major versions of a library to be installed at the same time. On ELF systems this is called the <tt style="white-space: nowrap;">soname</tt>. What's different on Darwin is that you can (and should) specify a full path along with the file name. This eliminates the need for "rpath" options and the ldconfig/ld.so.cache system. To use a library that is not yet installed, you can set the DYLD_LIBRARY_PATH environment variable; see the dyld man page for details.</p>

			<p>The Mach-O format also offers real minor version checking, unknown on ELF systems. Every Mach-O library carries two version numbers: a "current" version and a "compatibility" version. Both version numbers are written as three numbers separated by dots, e.g. 1.4.2. The first number must be non-zero. The second and third number can be omitted and default to zero. When no version is specified, it will default to 0.0.0, which is some kind of wildcard value.</p>

			<p>The "current" version is for informational purposes only. The "compatibility" version is used for checking as follows. When an executable is linked, the version information from the library is copied into the executable. When that executable is run, the stored version information is checked against the version information in the library that is loaded. dyld generates a run-time error and terminates the program unless the loaded library version is equal to or newer than the one used during linking.</p>

		

		<h3><a name="shared.cflags">2.3 Compiler Flags</a></h3>
			

			<p>The generation of position-independent code (PIC) is the default on Darwin. Actually, PowerPC code is position-independent by design, so there is no performance or space penalty involved. So, you don't need to specify a PIC option when compiling code for a shared library or module. However, the linker doesn't allow "common" symbols in shared libraries, so you must use the <tt style="white-space: nowrap;">-fno-common</tt> compiler option.</p>

		

		<h3><a name="shared.build-lib">2.4 Building a Shared Library</a></h3>
			

			<p>To build a shared library, you invoke the compiler driver with the <tt style="white-space: nowrap;">-dynamiclib</tt> option. This is best demonstrated by a comprehensive example. We'll build a library called libfoo, composed of the source files <tt style="white-space: nowrap;">source.c</tt> and <tt style="white-space: nowrap;">code.c</tt>. The version number is 2.4.5, where 2 is the major revision (incompatible API change), 4 is the minor revision (backwards-compatible API change) and 5 is the bugfix revision count (some people call this the "teeny" revision, it denotes fully compatible changes). The library depends on no other shared libraries and will be installed in <tt style="white-space: nowrap;">/usr/local/lib</tt>.</p>

<pre>cc -fno-common -c source.c
cc -fno-common -c code.c
cc -dynamiclib -install_name /usr/local/lib/libfoo.2.dylib \
 -compatibility_version 2.4 -current_version 2.4.5 \
 -o libfoo.2.4.5.dylib source.o code.o
rm -f libfoo.2.dylib libfoo.dylib
ln -s libfoo.2.4.5.dylib libfoo.2.dylib
ln -s libfoo.2.4.5.dylib libfoo.dylib</pre>
<p>
Note which parts of the version are used where.
When linking against this library, one would normally use the <tt style="white-space: nowrap;">-lfoo</tt> flag, which accesses the <tt style="white-space: nowrap;">libfoo.dylib</tt> symlink. Regardless of which symlink or file is specified, though, it is the <tt style="white-space: nowrap;">install_name</tt> that is written into one's program. That means one can delete the "higher" (less version-specific) symlink <tt style="white-space: nowrap;">libfoo.dylib</tt> after compiling. During a minor-revision library upgrade, one just changes the target of the <tt style="white-space: nowrap;">libfoo.2.dylib</tt> symlink that is used by the runtime dynamic linker.
</p>



<h3><a name="shared.build-mod">2.5 Building a Module</a></h3>
<p>
To build a loadable module, you invoke the compiler driver with the
<tt style="white-space: nowrap;">-bundle</tt> option.
If the module uses symbols from the host program, you'll have to
specify <tt style="white-space: nowrap;">-undefined suppress</tt> to allow undefined symbols,
and <tt style="white-space: nowrap;">-flat_namespace</tt> along with it to make the new linker
in Mac OS X 10.1 happy.
A comprehensive example:
</p>
<pre>cc -fno-common -c source.c
cc -fno-common -c code.c
cc -bundle -flat_namespace -undefined suppress \
 -o mymodule.so source.o code.o</pre>
<p>
Note that no version numbering is used.
It is possible to use it in theory, but in practice it's pointless.
Also note that there are no naming restrictions for bundles.
Some packages prefer to prepend "lib" anyway because some other
systems require it; this is harmless, since a program would use the full filename when loading a module.
</p>



<h2><a name="libtool">3 GNU libtool</a></h2>




<p>
GNU packages that build libraries use GNU libtool to hide
platform-dependent procedures for library building and installation.
</p>


<h3><a name="libtool.situation">3.1 The Situation</a></h3>
<p>
In the wild, one can find four strands of libtool:
</p>
<ul>

<li><p>
<b>libtool 1.3</b>:
The most common strand.
The last release from this branch is 1.3.5.
It doesn't know about Darwin and only builds static libraries.
It can be recognized by the presence of the files
<tt style="white-space: nowrap;">ltconfig</tt> and <tt style="white-space: nowrap;">ltmain.sh</tt> in
the source tree.
</p></li>

<li><p>
<b>libtool 1.4</b>:
Long in the works and recently released as the new
stable version, this branch has better autoconf integration.
Unfortunately that makes migrating packages from 1.3 non-trivial.
It supports Darwin 1.3 / Mac OS X 10.0 out of the box and needs a
small patch to work on Mac OS X 10.1.
It can be recognized by the absence of <tt style="white-space: nowrap;">ltconfig</tt>.
Versions that identify themselves as 1.3b or 1.3d are actually
development snapshots of 1.4 and must be treated with caution.
</p></li>

<li><p>
<b>The multi-language-branch</b>:
Also called MLB, this version of libtool was a parallel development
branch that added support for C++ and Java (via gcj).
It has now been merged back into the main development line.
Recent versions support Darwin 1.3 and Mac OS X 10.0 out of the box.
The MLB can be recognized by the files <tt style="white-space: nowrap;">ltcf-c.sh</tt>,
<tt style="white-space: nowrap;">ltcf-cxx.sh</tt> and <tt style="white-space: nowrap;">ltcf-gcj.sh</tt>.
</p></li>

<li><p>
<b>The current development branch</b>:
This is the development version that will some day be released as
libtool 1.5.
It has resulted from the merge of 1.4 and the MLB.
It supports C, C++ and Java (via gcj).
Unfortunately, it can't be easily told apart from 1.4, you'll have to
check the version number inside <tt style="white-space: nowrap;">ltmain.sh</tt>.
</p></li>

</ul>
<p>
In conclusion, libtool 1.3.x and packages that use it (which
happens to be the majority of libtool-using packages out there) need a
patch to build shared libraries on Darwin.
Apple includes a patched version of libtool 1.3.5 in Mac OS X, but it
will not work correctly in most cases.
Christoph Pfisterer improved that patch to hardcode the correct path and to 
do full versioning.
The changes were incorporated into upstream libtool releases and
development versions starting with 1.4.
Members of the Fink team continue to make improvements and forward them to 
the libtool maintainers.
The versioning scheme is compatible across all libtool versions.
</p>
<p>
Side note:
The libltdl library included with all libtool versions will only work
on Darwin when dlcompat is installed.
This is included with OS X starting with 10.3. For previous versions,
one can install the fink "dlcompat" family of packages.
</p>



<h3><a name="libtool.patch-135">3.2 The 1.3.5 Patch</a></h3>
<p>
If you are building libtool 1.3.5 for yourself, you will need to apply
<a href="http://www.finkproject.org/files/libtool-1.3.5-darwin.patch">this
patch</a> <b>[updated 2002-06-09]</b> to the libtool 1.3.5 source and
then delete the files ltconfig and ltmain.sh.
(They will be recreated from the appropriate .in files when you run
configure and make.)  This is done automatically, by the way, in the 
current Fink package for libtool 1.3.5.</p><p>
But that's only half the work - every package using libtool comes with
its own copies of <tt style="white-space: nowrap;">ltconfig</tt> and <tt style="white-space: nowrap;">ltmain.sh</tt>.
So you must replace these in every package that you want to build as a
shared library.
Note that you must do this before running the configure script.
For your convenience, you can get the two files right here:
<a href="http://www.finkproject.org/files/ltconfig">ltconfig</a> (98K) and
<a href="http://www.finkproject.org/files/ltmain.sh">ltmain.sh</a> (110K)
<b>[both updated 2002-06-09]</b>.</p>


<h3><a name="libtool.fixing-14x">3.3 Fixing 1.4.x</a></h3>
<p>
There are at least three different versions of libtool 1.4.x now in wide use
(1.4.1, 1.4.2, and later development snapshots). They all have some issues on
Darwin, though the exact changes required to fix them differ. The "libtool14"
package shipped via Fink has all required patches already applied to it.
However, you still have to manually fix the <tt style="white-space: nowrap;">ltmain.sh</tt> and <tt style="white-space: nowrap;">configure</tt> files of
affected packages in order to get them working.
</p>

<ol>
<li>
<b>The flat_namespace bug</b>:
This problem only occurs if you use libtool on Mac OS X10.1 and later. What happens
is that libtool tries to use the <tt style="white-space: nowrap;">-undefined suppress</tt> to allow undefined
symbols, but doesn't specify along with it the <tt style="white-space: nowrap;">-flat_namespace</tt> option.
Starting with 10.1 this won't work anymore. A typical patch looks like this:
<pre>
diff -Naur gdk-pixbuf-0.16.0.old/configure gdk-pixbuf-0.16.0.new/configure
--- gdk-pixbuf-0.16.0.old/configure	Wed Jan 23 10:11:48 2002
+++ gdk-pixbuf-0.16.0.new/configure	Thu Jan 31 03:19:54 2002
@@ -3334,7 +3334,7 @@
     ;;
 
   darwin* | rhapsody*)
-    allow_undefined_flag='-undefined suppress'
+    allow_undefined_flag='-flat_namespace -undefined suppress'
     # FIXME: Relying on posixy $() will cause problems for
     #        cross-compilation, but unfortunately the echo tests do not
     #        yet detect zsh echo's removal of \ escapes.
</pre>
</li>
<li>
<b>The loadable module bug</b>:
This bug is caused by the non-standard behaviour of zsh (which is the default
shell in 10.0 and 10.1; starting in 10.2 bash is the default).
Zsh's non-standard quoting behaviours prevents loadable module from being built
correctly, they end up as shared libraries instead (unlike Linux, these are
reall different things on Darwin). A typical fix for this (cut off, so you can't
use it unmodified):
<pre>
diff -Naur gnome-core-1.4.0.6.old/configure gnome-core-1.4.0.6.new/configure
--- gnome-core-1.4.0.6.old/configure	Sun Jan 27 08:19:48 2002
+++ gnome-core-1.4.0.6.new/configure	Fri Feb  8 01:10:21 2002
@@ -4020,7 +4020,7 @@
     # FIXME: Relying on posixy $() will cause problems for
     #        cross-compilation, but unfortunately the echo tests do not
     #        yet detect zsh echo's removal of \ escapes.
-    archive_cmds='$nonopt $(test "x$module" = xyes &amp;&amp; echo -bundle || echo -dynamiclib) ...'
+    archive_cmds='$nonopt $(test x$module = xyes &amp;&amp; echo -bundle || echo -dynamiclib) ...'
     # We need to add '_' to the symbols in $export_symbols first
     #archive_expsym_cmds="$archive_cmds"' &amp;&amp; strip -s $export_symbols'
     hardcode_direct=yes
</pre>
<p>
This problem is fixed in some post-1.4.2 versions of libtool.
</p>
</li>
<li>
<b>The convenience library bug</b>:
Under some conditions, libtool will fail to link convenience libraries, 
giving "multiple definitions" errors.
This is caused by a more fundamental problem in libtool it seems. For now 
as a workaround (curing the symptoms
not the actual problem, but with great success anyway), you can use this fix
(thanks to Dave Vasilevsky):
<pre>
--- ltmain.sh.old       2002-04-27 00:01:23.000000000 -0400
+++ ltmain.sh   2002-04-27 00:01:45.000000000 -0400
@@ -2894,7 +2894,18 @@
        if test -n "$export_symbols" &amp;&amp; test -n "$archive_expsym_cmds"; then
          eval cmds=\"$archive_expsym_cmds\"
        else
+         save_deplibs="$deplibs"
+         for conv in $convenience; do
+       tmp_deplibs=
+       for test_deplib in $deplibs; do
+         if test "$test_deplib" != "$conv"; then
+           tmp_deplibs="$tmp_deplibs $test_deplib"
+         fi
+       done
+       deplibs="$tmp_deplibs"
+         done
          eval cmds=\"$archive_cmds\"
+         deplibs="$save_deplibs"
        fi
        save_ifs="$IFS"; IFS='~'
        for cmd in $cmds; do
</pre>
</li>
<li>
<b>The DESTDIR bug</b>:
Certain packages which set DESTDIR and use libtool 1.4.2 have problems
with relinking.
The problems are discussed in these email messages: 
<p>
<a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00019.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00019.html</a></p>
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00021.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00021.html</a></p>
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00025.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00025.html</a>,</p>
<p>and a patch for the problem is discussed in:</p>
<p><a href="http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html">http://mail.gnu.org/archive/html/libtool/2002-04/msg00043.html</a>.</p>
</li>
</ol>


<h3><a name="libtool.notes">3.4 Further Notes</a></h3>
<p>For more information on libtool itself and what it does, see the <a href="http://www.gnu.org/software/libtool/libtool.html">libtool homepage</a>.</p>

<p>
Side note:
Apple's Developer Tools contain a program also called libtool, which
is used by the compiler driver to build shared libraries.
However, this is completely unrelated with GNU libtool.
The GNU libtool that Apple ships is installed as <tt style="white-space: nowrap;">glibtool</tt>
instead.
This can be achieved by configuring GNU libtool with
<tt style="white-space: nowrap;">--program-transform-name=s/libtool/glibtool/</tt>.
</p>


<h2><a name="preparing-10.2">4 Preparing for 10.2</a></h2>




<h3><a name="preparing-10.2.bash">4.1 The bash shell</a></h3>
<p>
Fink made the transition from OS X 10.0 to OS X 10.1 fairly easily, thanks
in part to planning ahead for the changes that were coming.  We will try
to do the same for the next transition, but not many details are known
yet. </p>
<p> We understand that OS X 10.2 will use bash rather than zsh to provide
<tt style="white-space: nowrap;">/bin/sh</tt> functionality.  This has at least three implications
for fink. 
</p>
<ul><li>
In the past, some fink packages created a CompileScript (or PatchScript or
InstallScript) which does nothing
by simply putting a semicolon in the script.  This does not work
under bash, and must be replaced by something like
<pre>
  CompileScript: echo "nothing to do"
</pre>
</li>
<li>
In the past, some fink packages used a the <tt style="white-space: nowrap;">lib(foo|bar).dylib</tt>
construction to refer to two libraries at once; this doesn't work under
bash (and the bash alternative <tt style="white-space: nowrap;">lib{foo,bar}.dylib</tt> doesn't work
under zsh).  Solution: write out the names in full.
</li>
<li>
A libtool patch is needed in many cases, to prevent libraries from being
build unversioned under bash.  
<b> Note: you do not need this patch with
 libtool-1.3.5, for example, if you are using UpdateLibtool:
 True. </b>
The symptom: when building under bash,
you see
<pre>
../libtool: test: too many arguments
</pre>
When this happens, <tt style="white-space: nowrap;">configure</tt> contains the following:
<pre>
archive_cmds='$CC $(test .$module = .yes &amp;&amp; echo -bundle || echo 
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts 
-install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != 
x0.0 &amp;&amp; echo $verstring)'
</pre>
Here is a patch (but it must be used with care, because sometimes there are
other libtool problems as well so this patch must be applied by hand):
<pre>
diff -Naur gdk-pixbuf-0.16.0/configure gp-new/configure
--- gdk-pixbuf-0.16.0/configure 2002-01-22 20:11:48.000000000 -0500
+++ gp-new/configure    2002-05-10 03:02:44.000000000 -0400
@@ -3338,7 +3338,7 @@
      # FIXME: Relying on posixy $() will cause problems for
      #        cross-compilation, but unfortunately the echo tests do not
      #        yet detect zsh echo's removal of \ escapes.
-    archive_cmds='$CC $(test .$module = .yes &amp;&amp; echo -bundle || echo 
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts 
-install_name $rpath/$soname $(test -n "$verstring" -a x$verstring != 
x0.0 &amp;&amp; echo $verstring)'
+    archive_cmds='$CC $(test .$module = .yes &amp;&amp; echo -bundle || echo 
-dynamiclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linkopts 
-install_name $rpath/$soname $tmp_verstring'
      # We need to add '_' to the symbols in $export_symbols first
      #archive_expsym_cmds="$archive_cmds"' &amp;&amp; strip -s $export_symbols'
      hardcode_direct=yes
diff -Naur gdk-pixbuf-0.16.0/ltmain.sh gp-new/ltmain.sh
--- gdk-pixbuf-0.16.0/ltmain.sh 2002-01-22 20:11:43.000000000 -0500
+++ gp-new/ltmain.sh    2002-05-10 03:04:49.000000000 -0400
@@ -2862,6 +2862,11 @@
        if test -n "$export_symbols" &amp;&amp; test -n "$archive_expsym_cmds";
	then
          eval cmds=\"$archive_expsym_cmds\"
        else
+         if test "x$verstring" = "x0.0"; then
+           tmp_verstring=
+         else
+           tmp_verstring="$verstring"
+         fi
          eval cmds=\"$archive_cmds\"
        fi
        IFS="${IFS=     }"; save_ifs="$IFS"; IFS='~'
</pre>
</li>
</ul>

<h3><a name="preparing-10.2.gcc3">4.2 The gcc3 compiler</a></h3>

	<p>Mac OS X 10.2 uses the gcc3 compiler.</p>
	
	<p>Some packages which have loadable modules and use
libtool fail with an install_name error, because libtool passes
the -install_name flag even along with the -bundle flag (when it is not
strictly needed).  This behavior was accepted by the gcc2 compiler but is
not being accepted by the gcc3 compiler.  The fix can be found <a href="http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg02025.html">here.</a>
Note that you do not need the patch if your package uses libtool-1.3.5
(for example, if you are using <tt style="white-space: nowrap;">UpdateLibtool: True</tt>)
since it has already been incorporated into a revised version of fink's
ltconfig file (available in pre-release versions of fink).
</p>

<p>Another issue with the gcc3 compiler is an incompatibility for C++ ABIs
between gcc2 and gcc3.  In practice, this means that C++ programs compiled
with gcc3 cannot link to libraries compiled with gcc2.</p>




<h2><a name="preparing-10.3">5 Preparing for 10.3</a></h2>



<h3><a name="preparing-10.3.perl">5.1 Perl</a></h3>

  <p>
    In OS X 10.2, <tt style="white-space: nowrap;">/usr/bin/perl</tt> was perl 5.6.0
    and the architecture string was "darwin". In OS X
    10.3, <tt style="white-space: nowrap;">/usr/bin/perl</tt> was upgraded to perl
    5.8.1 and the architecture string was changed to
    "darwin-thread-multi-2level". These changes <b>probably</b> do
    not affect ordinary uses of the perl executable for package
    creation since each perl executable knows where to find its own modules.
    Maintainers of perl-module ("-pm") packages who follow the current
    <a href="http://www.finkproject.org/packaging/policy.php#perlmods">Perl
    Modules packaging policy</a> and are careful to follow the
    <tt style="white-space: nowrap;">CompileScript</tt> and <tt style="white-space: nowrap;">InstallScript</tt>
    documentation will already have things set up correctly.
  </p>



<h3><a name="preparing-10.3.typedef">5.2 New symbol definitions</a></h3>

  <p>
    Starting in Mac OS X 10.3, there is now always a complete
    definition for the <tt style="white-space: nowrap;">socklen_t</tt> type. To get this
    typedef defined, you may need to add to your program:
  </p>
  <pre>
#include &lt;sys/types.h&gt;
#include &lt;sys/socket.h&gt;
  </pre>



<h3><a name="preparing-10.3.system-libs">5.3 New builtin system libraries</a></h3>

  <p>
    Mac OS X 10.3 includes several libraries that were not in previous
    system releases, and so were provided as fink packages:
  </p>

  <table border="0" cellpadding="0" cellspacing="10"><tr valign="bottom"><th align="left">Field</th><th align="left">Value</th></tr><tr valign="top"><td>libpoll</td><td>
	<p>
	  The files <tt style="white-space: nowrap;">/usr/lib/libpoll.dylib</tt> and
	  <tt style="white-space: nowrap;">/usr/include/poll.h</tt> are now included,
	  however the OS X-supplied implementation of this library is
	  not complete. If it is sufficient for your purposes, you can
	  remove dependencies on the Fink "libpoll" and
	  "libpoll-shlibs" packages. The library code is
	  actually incorporated into libSystem, which is automatically
	  linked. That means that <tt style="white-space: nowrap;">-lpoll</tt> is not necessary
	  if you wish to use the OS X implementation. Be aware that OS
	  X supplies a <tt style="white-space: nowrap;">libpoll.dylib</tt>, so
	  <tt style="white-space: nowrap;">-lpoll</tt> may give different results depending on
	  whether you have the Fink "libpoll" package
	  installed or not.
	</p>
      </td></tr><tr valign="top"><td>libdl</td><td>
	<p>
	  The files <tt style="white-space: nowrap;">/usr/lib/libdl.dylib</tt>
	  and <tt style="white-space: nowrap;">/usr/include/dlfcn.h</tt> are now included, so you should
	  not need dependencies on the Fink "dlcompat",
	  "dlcompat-dev", and "dlcompat-shlibs" packages. The library
	  code is actually incorportated into libSystem, which is
	  automatically linked. That means that <tt style="white-space: nowrap;">-ldl</tt> is
	  not necessary (but has no effect if used).
	</p>
      </td></tr><tr valign="top"><td>GNU getopt</td><td>
	<p>
	  This library, including the <tt style="white-space: nowrap;">getopt_long()</tt>
	  function, has been incorportated into libSystem and
	  <tt style="white-space: nowrap;">/usr/include/getopt.h</tt>, so you may not
	  need to use the Fink "libgnugetopt" and
	  "libgnugetopt-shlibs" packages. Because libSystem is
	  automatically linked and <tt style="white-space: nowrap;">/usr/include</tt>
	  is automatically searched for headers, you could remove any
	  <tt style="white-space: nowrap;">-lgnugetopt</tt>
	  and <tt style="white-space: nowrap;">-I/sw/include/gnugetopt</tt> flags that were
	  manually added in order to access Fink's
	  "libgnugetopt".
	</p>
      </td></tr></table>

  <p>
    When migrating a package to OS X 10.3, try to remove these
    deprecated dependencies, as those packages may be removed from these
    newer package trees in the future. This means you will need a separate
    package description file for each tree. As always,
    the <tt style="white-space: nowrap;">Revision</tt> must be increased when making changes to
    a package. In this manner, a user who upgrades from OS X 10.2 to
    10.3 will see 10.3-specific packages as "newer" than his
    existing 10.2 ones. By convention, the <tt style="white-space: nowrap;">Revision</tt>
    should be increased by 10 when changes are made for migration to a
    higher tree inn order to leave space for the lower-tree package to be
    updated in the future.
  </p>

  <p>
    When testing a migrated package, make sure to uninstall the
    packages whose <tt style="white-space: nowrap;">BuildDepends</tt> you removed. Otherwise
    the compiler may still link the Fink-supplied libraries.
  </p>



<h2><a name="preparing-10.4">6 Preparing for 10.4</a></h2>



<h3><a name="preparing-10.4.perl">6.1 Perl</a></h3>

  <p>
    <tt style="white-space: nowrap;">/usr/bin/perl</tt> is now perl 5.8.6; the
    architecture string is still "darwin-thread-multi-2level".
  </p>



<h3><a name="preparing-10.4.typedef">6.2 New symbol definitions</a></h3>

  <p>
    Mac OS X 10.4 has changed the types of many symbols. If you
    previously set a type explicitly, for example,
    defining <tt style="white-space: nowrap;">socklen_t</tt> as <tt style="white-space: nowrap;">int</tt>, that
    definition may no longer be correct.
  </p>



<h3><a name="preparing-10.4.system-libs">6.3 New builtin system libraries</a></h3>

  <p>
    The <tt style="white-space: nowrap;">poll()</tt> function in Mac OS X 10.3 was actually an
    emulation implemented using <tt style="white-space: nowrap;">select()</tt>. In Mac OS X
    10.4, <tt style="white-space: nowrap;">poll()</tt> is a real function implemented in the
    kernel, however it is broken when used with sockets. Consider
    ignoring the system's <tt style="white-space: nowrap;">poll()</tt> completely. Fink's glib2
    package has been patched to use a fully functional emulation, so
    it is safe to use that library's implementation of poll-like
    functions.
  </p>



<hr><h2>Copyright Notice</h2><p>Copyright (c) 2001 Christoph Pfisterer,
Copyright (c) 2001-2011 The Fink Project.
You may distribute this document in print for private purposes,
provided the document and this copyright notice remain complete and
unmodified. Any commercial reproduction and any online publication
requires the explicit consent of the author.</p><hr>
<p>Generated from <i>$Fink: porting.en.xml,v 1.8 2007/02/23 22:04:55 rangerrick Exp $</i></p></body></html>
